An adaptive bit rate (ABR) streaming client typically balances a need to pipeline GET requests (in order to keep the pipe full and maximize throughput) with a need to gather throughput data (in order to determine the rate of the next fetch in order to be responsive to congestion signals and make upshift/downshift decisions). This is particularly important when the client is trying to grow the amount of data in the client's playback buffer. When the GET is active, Transmission Control Protocol (TCP) is operative to fill the pipe and thus on certain networks the network buffers become full. The round trip time (RTT) from the client to the server and back to the client is different at the end of the data fetch than at the start. It can be substantially different. Each subsequent fetch can build additional delay into the system. In fact, on poorly designed tail drop systems, the delay may deterministically build up until it reaches the limits of the buffer, and then level-out at that value. Variable cross traffic may also cause variable delay for the ABR flow. A very naive client may simply wait until the current chunk arrives in its entirety, calculate the network rate, determine the rate for the next chunk, and then fetch the next chunk. This causes approximately one RTT of dead time on the network. A slightly more effective client will pipeline the GETs by fetching the next chunk at a fixed offset from the end of the current chunk. This is better than waiting until the current chunk arrives in its entirety.